home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0683.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.7 KB  |  70 lines
  1.  
  2.  
  3. Logging user access is something which we definitely want ..for a  
  4. number of reasons
  5.  
  6.     -  Justifying the project by showing statistics
  7.     -  Demonstrating the readership profiles of 
  8.  
  9.         different material
  10.     -  Demonstrating the usage profile across sites
  11.     
  12. The privacy issue is very important, and so I had intended to
  13. log each action "A read B" as "A read something" and "B was read"
  14. independently.  This would give the basic profiles.  Anything futher  
  15. would be an infringement of privacy, so yes that the user would
  16. have to agree to it. The problem is, then the sociological data would  
  17. be immediatly filtered ... all the alt.sex.bondage readers would
  18. filter themselves out!  Perhaps two levels are needed.
  19.  
  20. The network load is also something which I considered a possible  
  21. problem, so I decided on a scheme (have I said this before?) in which
  22. an event was logged with probability p=exp(-a*t) and the probability
  23. p is included in the message so that the message can be given weight  
  24. 1/p in the analysis. The time t with which p decays is from  
  25. compilation of the source, so you get more fine-grained
  26. info on the new releases.
  27. The messages would be UDP packets so as not to clog gateways.
  28.  
  29. We have a monitoring service here which is already monitoring the use  
  30. of other CERN software -- I am not sure whether it is tcp or udp  
  31. based.  
  32.  
  33.  
  34. *Coincidence:*  As I write the file system on our server has JUST  
  35. filled up in attempting to process server January's log data....
  36. is this a warning?!
  37.  
  38. BTW: Marc, you were going to log how LONG an article was read for.
  39. I think that is very tricky... if you can come up with a good measure
  40. of how much the person LIKED the article (automatically) then you
  41. will really have something.  Someone whose name I forget in Stockholm
  42. just gave a talk about inferrding document affinities from readership  
  43. profiles... using the user  as a more refined text comparison program
  44. than a work occurence engine.  I suggested WWW usage data as source,
  45. but realized that for example of all the talk I had just given with
  46. XMosaic, the document which was left on the screen for the longest  
  47. time was quite irrelevant.
  48.  
  49. Something linked with this is finding relevant material for
  50. a particular person.  How about a service which takes someone's
  51. global history file and tells them all that's new in the world
  52. which would interest them?  In other words, if you do keep
  53. data about a particular person, then that can help them find more  
  54. data like it.... a sophisticated form of relevance feedback.
  55.  
  56.  
  57.  - - -
  58.  
  59.  
  60. I think that as you are collecting data from the public, then the
  61. data should also be made available to the public, with names and
  62. addresses removed.
  63.  
  64. Another possibility is that all servers keep logs and share the
  65. results... but it will always be incomplete.
  66.  
  67.  
  68. Tim
  69.  
  70.